The following discussion of the background to the invention is intended to facilitate an understanding of the present invention only. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was published, known or part of the common general knowledge of the person skilled in the art in any jurisdiction as at the priority date of the invention.
Throughout the specification, unless the context requires otherwise, the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
Furthermore, throughout the specification, unless the context requires otherwise, the word “include” or variations such as “includes” or “including”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
Field devices are instruments or transmitters that are used to obtain process variables in an equipment or part of an industrial process in an industrial facility or plant. Some field devices are used as measurement meters to obtain specific process variables. For example, a field device can be used as a temperature transmitter for temperature process variable, a flow meter for flow rate process variable, and a pressure transmitter for pressure process variable.
Most known field devices are configured to function according to one of the standard communication protocols, such as HART, or Foundation Fieldbus. A field device which uses HART communication protocol will be hereinafter be referred to as a HART field device, one using Foundation Fieldbus is FF-H1 field device.
Before deployment, field devices have to be commissioned. Commissioning is a process for testing if the field devices, equipment, facility or industrial plant will perform one or more specified functions according to design objectives or specifications. The commissioning is typically done by performing a manual work check function, which is tedious, time consuming and prone to human errors. These errors include incorrect procedures such as the inadvertent skipping of certain steps to be carried out or a deviation from the proper sequence in testing, both which result in errors or inaccurate test results.
To mitigate the above problems associated with manual commissioning, the Applicant had developed a commissioning tool. The commissioning tool is a device management system with an integrated commissioning tool aimed towards reducing commissioning time, cost and improving commissioning quality. For each type of field device and related functions, the commissioning tool is operable to pre-program the various testing steps and sequences, automate certain steps and ensure that the testing sequences are properly adhered to. To this end, an important function of the commissioning tool is an import device operation that allows user to import source files relating to the field device into the commissioning tool. Once a source file is imported, the commissioning tool may then, where necessary, convert the source file into a device list file and a mapping list file for the use of commissioning.
An example of the import device operation, from a user's perspective is as follows:
i. Users select one or more source files to import;
ii. Users initiate the import device operation by clicking on a button (e.g. a “Next” button) on a graphical user interface provided. Once the command is received by the commissioning tool, the system loads an “Importing devices progress” page to be shown to inform users that the commissioning tool is validating the source files.
iii. After validation, a “Summary” interface page may be displayed comprising                a. valid device information;        b. invalid device information; and        c. conflict between new and existing information.        The content of this summary page depends on whether all information in the source files is valid and whether conflicts exist between the new data and existing data. It is to be appreciated that all invalid devices are removed and only valid devices will be processed after this step.        
iv. If there exist conflicts between new and existing information, and users want to resolve the conflict, a Conflict Resolution user interface is shown to allow users to resolve the conflict. Users can also reset task related to conflict device if needed.
v. An “Import Devices results” user interface page is shown if the user does not cancel the Import Devices operation and there is no “Import Devices failed” page is shown.
If errors are found within the source files, the errors are sent to one or more error detail files. The error detail provides information about the field device having error and the name of source file that contains the error devices so that users can have information to fix errors in these files. Simultaneously, the import device operation is aborted.
Therefore, with the existing system, if users wish to import devices that have errors, they have to manually modify or resolve the error within the source file before repeating the import device operation. Such modification or resolution is typically time consuming and tedious. In the manual modification or resolution process, users often have to rely on trial and error or certain amount of guesswork to arrive at a suitable correction to resolve the error.
In addition, as the import process is aborted whenever an error is detected, easily rectifiable errors typically generated due to typographical error or omission of certain entries in the source file will inadvertently trigger an ‘import abort’ which require the import device operation to be repeated. This unnecessarily adds on to the overall time taken for importation, reduces efficiency and increases frustration on the part of the users.
It is therefore an object of the invention to meet the above needs and alleviate the challenges at least in part.